You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
currentCueId and nextCueId were per-show with no cross-show exclusivity. Setting a cue as current or next in one show had no effect on other shows, allowing multiple concurrent current/next pointers application-wide.
Changes
assignShowCuePointer — wrapped in a transaction; when assigning a non-null pointer, clears the same field in all other shows and publishes show.currentCueChanged / show.nextCueChanged events for each cleared show before publishing the target show's event
takeShow — single-pass loop over other shows clears currentCueId unconditionally (take always produces a new current cue) and clears nextCueId only when a non-null following cue is being assigned; saves all affected rows in one call within the existing transaction
resetShow — unchanged; clearing a single show's pointers doesn't violate global uniqueness
What changed — Only src/server/services/show-service.ts was modified:
assignShowCuePointer: Now wrapped in a transaction. When setting a non-null pointer, it loads all other shows, clears the same field in any that have it set (also clearing currentCueTakenAt when the field is currentCueId), saves them, then publishes show.currentCueChanged / show.nextCueChanged events for each cleared show before publishing the event for the target show. Clearing a pointer (setting to null) doesn't touch other shows, which is correct — no global invariant is violated when clearing.
takeShow: A single pass over all other shows clears currentCueId unconditionally (a take always produces a new non-null current cue) and clears nextCueId only when a non-null followingCueId is being assigned (global uniqueness of the next pointer is only relevant when a cue actually becomes next). All affected rows are saved in one call inside the existing transaction, then cleared events are published before the target show's update events.
resetShow: Unchanged — clearing a single show's pointers doesn't introduce a duplicate, so no cross-show work is needed.
Correctness notes:
All DB mutations (clearing other shows + writing the target show) are inside the same transaction, so a mid-operation failure leaves no partial state.
Realtime events for cleared shows use the cleared show's own showId as the key, so clients subscribed to those shows receive the invalidation signal correctly via the existing showEvents bus.
entityId?: string is optional in ShowEvent, so passing undefined for cleared shows is type-correct and consistent with other clear-type events in the codebase (e.g., resetShow).
When followingCueId is null (last cue taken), other shows' nextCueId is intentionally not cleared — no cue is becoming next, so the global-uniqueness invariant isn't triggered.
No issues found. The implementation is minimal, atomic, and correctly propagates realtime events to all affected clients.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
currentCueIdandnextCueIdwere per-show with no cross-show exclusivity. Setting a cue as current or next in one show had no effect on other shows, allowing multiple concurrent current/next pointers application-wide.Changes
assignShowCuePointer— wrapped in a transaction; when assigning a non-null pointer, clears the same field in all other shows and publishesshow.currentCueChanged/show.nextCueChangedevents for each cleared show before publishing the target show's eventtakeShow— single-pass loop over other shows clearscurrentCueIdunconditionally (take always produces a new current cue) and clearsnextCueIdonly when a non-null following cue is being assigned; saves all affected rows in one call within the existing transactionresetShow— unchanged; clearing a single show's pointers doesn't violate global uniqueness